Volume 1

Issue 2

June 2004

People, Processes, and Change Issues in Information Architecture Pamela Kostur, The Rockley Group Behind a successful content management implementation is a solid information architecture that describes such things as how information products will be structured, where and how content (and structure) will be reused, as well as what metadata is required to identify how content is used, retrieved, and tracked. Information architecture forms the specification for a unified content strategy, but information architecture brings a new set of challenges to those whose job is to create and disseminate content. This article explores some of the issues specific to information architecture, including: teaching authors about information architecture; distinguishing between reusable content and reusable structure; visually representing information structure (documenting your information architecture); and documenting the architecture. When organizations attempt to unify their content, they start by analyzing a select set of content to see how it is currently used and where it can be used. Along with an analysis of the content, organizations must also examine the processes they follow to create, review, and manage content. Once they have a thorough understanding of the information needs within the organization (or within a department or departments), they can start unifying content, first by designing a new structure to support consistency and reuse, then by implementing the structure with new processes, and often, with new tools. Building the information architecture that describes the new structure is critical to a unified content strategy. However, many authors struggle with concepts related to information architecture. They often have difficulty modeling their content, describing their structure semantically, visualizing structure within and across information products, and they have difficulty understanding the technology well enough to know what type-and how much-information to include in their models so they will be implemented according to the authoring scenarios they envision. Teaching authors about information models Once organizations have identified opportunities to unify content, they need to model the content they plan to unify. Creating information models is the first stage of designing your information architecture. Models formalize the structure of content; they form the framework upon which the unified content strategy is based. As such, they are critical to the success of a unified content strategy. In general, authors create documentation-brochures and other marketing materials, press releases, user guides, technical specifications, product descriptions, training materials, policies, procedures, etc.. Their focus is typically on writing and editing (for many different media), on assessing user requirements and writing documentation to meet those requirements. However, information modeling asks them to examine documentation from an architectural perspective and across a number of different information products. For most authors, this is a different way of looking at documentation. Instead of focusing on writing and editing-the "normal" scope of work for most authors-information modeling asks them to examine their content structurally. When authors look at their content structurally, they examine how it can be put together so it is consistent and so elements can be reused across information products. Information modeling requires that authors determine: Which elements make up their information products and which element (based on granularity) belongs where Which elements share a reusable structure and which share reusable content The type of reuse that applies to each element (e.g., opportunistic, systematic, derivative, locked, nested) The semantic structure of each element, which uniquely identifies the element's content. Semantic tags are based on content (as opposed to format), helping authors to identify elements for reuse and to structure them consistently The metadata that applies to each element The base structure (or presentation) of each element (e.g., para, ulist, olist, title, and so on) Much of this is new to authors so before starting the modeling work, they may need to be educated in the process and language of information architecture (e.g., elements, granularity, the types of reuse, semantic structure, metadata). The modeling team also needs to go through some practice modeling exercises before tackling their own work. Once they have modeled something in which they have no vested interest, they are more comfortable modeling their own information products. Choosing members of the modeling team is also important. They need objectivity, plus the experience to help them to make decisions about the structure of their content. Accordingly, it is beneficial to have both experienced and newer members of authoring groups on modeling teams. An information modeling team will also need someone well versed in information architecture to lead it and to keep the team on track. Distinguishing reusable structure from reusable content One aspect of modeling that seems particularly problematic for authors is distinguishing between reusable structure and reusable content. Within a model, there may be elements that share a reusable structure, and others that share both structure and content. Both types of reuse need to be reflected in the model. For example, procedures (or portions of procedures) may have a reusable structure, so that wherever procedures appear, they are structured consistently. However, even though procedures may share a common structure, they do not always share content. Wherever elements share both content and structure, both types of reuse must be indicated in the model. Illustrating both reusable structure and reusable content adds another dimension to the information model. An information model is typically hierarchical. It shows the order in which elements appear within an information product. Where elements share reusable structure within that information product, or across other ones, we track the reusable structure separately, apart from the information product hierarchy. We do this by "linking" to another model that describes the structure of each reusable element, and indicates which parts of the structure belong where. This way, the main "hierarchical" model for an information product doesn't get bogged down in levels of reusable structure, making the hierarchy easier to see. Plus, we don't have to repeat reusable element structure over and over again; we simply link to the reusable elements. Furthermore, if an element takes reusable content, this needs to be indicated separately, for example, in a "reusable content" column on the information product model. In this way, the reusable content is kept separate from the reusable structure. In the reusable content column, the modeling team indicates if an element takes reusable content, if that content is inserted systematically or if authors look for it and insert it opportunistically, and if the reusable content is locked or editable. As before, this requires that authors think about content from an architectural perspective-both content and structure-and that they document structure and content reuse in a way that makes sense to their team, and to those who will be implementing the models. This poses a challenge for many organizations. Visualizing structure Regardless of how well the modeling team understands information architecture, visualizing structure remains difficult. Besides showing hierarchy, information models also show relationships among elements; for example, the use of one element may be dependent on another element being included. One of the best ways to represent hierarchy and relationships is in a spreadsheet, with the left column representing the semantic name of the element, and the columns to the right representing the element's usage across information products. If an element belongs in an information product, we use an "M" to indicate its usage is mandatory or an "O" to indicate it's optional. The model also carries other information, such as the reusable content notes, any production or writing notes, and the metadata that applies to the element. Because models contain so much information, they are difficult for authors to learn to read, and hence, verify. Models are usually "textual", with hierarchy and relationships being shown through a tabular structure. But, the models that represent information products don't exactly look like information products; in fact, a house blueprint looks more like a house than an information model looks like an information product. To assist authors in visualizing information products in their spreadsheet representation, we recommend "connecting" the model to the information products being modeled, possibly marking up actual information products to correspond to the parts of the model. Content is multi-dimensional, and it's difficult to represent its structure visually without a sample that accompanies the model. This marked-up information product is also useful for the DTD/authoring template developers; it gives them a clearer idea of what the authoring template should allow authors to do and what the output should look like. However, if you are making significant changes to the information products being modeled (and we recommend modeling what you want your information products to be, not necessarily what they are), or if you are modeling new information products, you may need to create a sample information product to go along with the model, marking it up to correspond with the model. Without information product samples that correspond to the information model, it's also very difficult for authors to verify the models. Documenting the architecture Once models are created and verified, they need to be implemented in DTDs or authoring templates, and the content needs to be managed in a CMS (content management system) or document server. The biggest issue in implementing models is ensuring that their implementation corresponds with what the modeling team envisions. Just like an architect gives a house builder a blueprint for a house and the builder follows it, an information architect gives the DTD/authoring template developer (and the person responsible for setting up the CMS) the blueprint for the information products. But, the model does not stand alone; it needs an implementation strategy to accompany it. The model illustrates the hierarchical structure of the information products; it shows the order of elements within an information product and where elements (both structure and content) are reused across information products. It also provides implementation details such the metadata, the presentation of each element (e.g., para, ulist, title), their frequency, etc. However, the model does not illustrate the authoring process, which is a critical part of the authoring template. Accordingly, along with the model, you need an "implementation strategy" that fully describes how you envision the authoring process, from the time authors sit down to write or edit the document, through to its being stored in the CMS or on a server. This strategy describes the implementation of your information architecture and should include such things as: How authors select the template for the various information products How the template is presented to them (e.g., in chapters/sections or in its entirety) and what rules apply to the template (e.g., Will optional elements be displayed? Will authors be able to proceed without writing the mandatory elements?) How systematically reusable content is retrieved and pulled into the template How authors search for opportunistically reusable content How content is tracked as it is updated/used in other information products, including how derivatives are tracked How locked content is updated How information products that have reusable content are updated when the reusable content elements are updated in other information products (e.g., are authors notified or is updating done automatically, without notifying authors) How metadata is added to the elements How content is stored or checked back into the CMS Many implementation issues are tool dependent and authors should work with the DTD/authoring template developers as well as the CMS experts to ensure their authoring vision will work in the selected tools. It's also useful to have the DTD/authoring template developers as members of the team defining your information architecture, so they share the same interpretations as the authors who create it and so they can guide authors in what is technically possible, given the tools they are using to create and manage their content Summary As information architects, or as those heading content management projects, we need to describe unified content and information structure in more familiar ways, at the beginning of projects and throughout their implementation. Looking at content management from an information perspective (i.e., beyond the purely systems perspective) is new for many of us. Everyone working on a unified content project-from management supplying the funding and the support through to the authors developing the models and the IT departments implementing and supporting the technology-needs a common understanding of what the models are and what they're intended to do. With that in mind, we need to: Educate everyone who will be involved in the unified content project about what unified content is and how information architecture supports it Teach everyone who will be participating in defining the information architecture (and its implementation) the language and the concepts of information architecture Find ways to create more visual information models, including mapping information models against existing information products (even if you have to create new ones), thus making them into visual aids that support the models Document the model in an "implementation strategy" that describes, in terms that authors are familiar with, how the model will be implemented, from the time they start writing, to the time the content is published and stored in the CMS Share the strategy with those who are creating the DTDs/templates and with those who are designing how the content will be stored/retrieved/tracked A unified content strategy is only as successful as the blueprint on which it is based. A solid information architecture forms the basis for the unified content strategy and it's critical that everyone involved in the project understands the strategy behind the architecture is, how to read the models, how to implement them, and how to move from their current authoring environment to the one described in the strategy.